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DYNAMIC DSCP AVAILABILITY REQUEST METHOD 

The present invention relates to the transmission of messages across different 
differentiated service communication networks. 

The boundaries between the various 'traditional 1 networks are becoming 
increasingly blurred. Nowadays, there is a significant overlap between 
applications traditionally in the telecommunications domain, i.e. circuit-switched 
traffic (voice) and applications traditionally in the data communication domain, i.e. 
packet-switched traffic (data). 

The two basic approaches to packet-switching are well known: 

i) "Connection-oriented" technique where during an initial phase a Virtual circuit 1 is 
first established between two end-users (analogous to a standard voice circuit) 
and then packet data is transmitted down this pipe. An example is the X.25 
network commonly used for public packet data networks. 

ii) "Connection-less" technique also known as datagram switching or a "best-effort 
network". An example of this approach is the Internet, which uses a datagram 
service where at each node (or router) the IP packet header is examined and the 
packet is routed to another intermediate node that is closer to the recipient. Thus, 
the packets are routed on a 'hop-by-hop' basis. 

One of the differences between these two approaches is that the packet structure 
of the "connection-oriented" approach can use short headers, because the path of 
the envisaged data stream (virtual circuit) has already been established. In 
contrast, the data packets for the connection-less approach can arrive at the 
receiver in any order and each packet is treated as a 'self-contained' entity and 
therefore the header needs to carry full information about the intended recipient. 

The unprecedented growth of the Internet has meant that network operators and 
service providers ISP's need to try and offer adaptable networks, which are 
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flexible in allowing a variety of traffic including not only traditional 1 data traffic but 
also voice traffic (such as VoIP), data packet applications of a 'bursty' nature and 
emerging multimedia applications which include bandwidth, latency and jitter 
requirements. 

The subject area concerned with the development of the various network 
architectures is constantly evolving to allow for possible future network expansion 
and/or more efficient implementation technologies. The IETF (Internet 
Engineering Task Force) attempts to standardise and coordinate working groups 
in emergent areas of Internet technology. One of these groups is the 
Differentiated Slices work group (DiffServ). However, due to the 
advancements in this area, much of the techniques associated with Differentiated 
Services are still under development. Differentiated service mechanisms allow 
providers to allocate different levels of service to different users of the Internet, 
while accommodating heterogeneous application requirements. 

QoS (Quality of Service) is an important set of parameters, which provide 
indication as to the quality of the service that can be expected from the network at 
a certain time. More generally, QoS is concerned with the measurement and 
improvement of transmission rates, error rates and trying to guarantee a certain 
level of transmission in advance. One of the major factors that influence the QoS 
is the amount of traffic on a communication network at any instant in time. The 
busier the network, the harder it will be for a 'bandwidth-intensive 1 application to 
obtain the required resources so that the transmission is of an acceptable quality. 
Certain applications (for example videophone) need to know the QoS to 
determine whether or not the service can be fully supported. 

Differentiated Services will be referred to herein as "DiffServ". it should also be 
noted that the terms 'node' and 'router 1 may be used interchangeably in this 
description, because the specific example provided is the Internet where routers 
are used to switch data traffic. 
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Various technologies including DiffServ and RSVP (Resource Reservation 
Protocol) have been suggested to allow for so-called 'QoS-aware' data transfer, 
especially in multimedia applications (such as videophone) that place high 
bandwidth demands on the network. The known solutions each have limitations, 
which the present invention attempts to overcome. 

Many modem "bandwidth-intensive" applications require a certain QoS to be 
certain that the application will be supported across the network. The Resource 
Reservation Protocol (RSVP) allows a host device to request a specific QoS from 
the network, on behalf of the application. To do this, the RSVP makes resource 
reservations for each node in the network that carries a particular application's 
data stream. Each node determines whether there are sufficient resources (i.e. 
bandwidth) to provide the required QoS value. The main drawbacks of RSVP are 
that this technique is complex, requires a lot of overhead processing in every hop 
and does not scale well. It is evident that the greater the number of nodes in a 
network, the more RSVP signalling will be required to determine whether a certain 
QoS can be sustained. 

The Differentiated Services architecture is also 'QoS aware 1 , however whereas 
RSVP incurs large overhead in negotiating sufficient resources from each node of 
an envisaged data path, no sjgnalling between nodes is required for DiffServ. 
Instead edge routers, within a DiffServ-capable network, 'mark 1 the header of 
each IP (Internet Protocol) packet making up a particular applications data stream 
with a certain priority value known as a code point. The intermediate nodes then 
identify the code point field, which is translated into a particular PHB (Per Hop 
Behaviour) and the packet is forwarded accordingly. The advantage of such a 
scheme is that the processing and associated storage circuitry for each 
intermediate router is considerably simplified since QoS is invoked on a per- 
packet basis. However, the present state of the Differentiated Services 
architecture, herein referred to as "basic DiffServ", also has inherent problems. 
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The per-packet code point values are set by the sending application. Therefore, 
basic DiffServ does not guarantee resources and the recipient is limited in 
controlling the QoS of the received data stream. Also, before transmitting the 
data stream the sender does not know which DSCP's (Differential Service Code 
points) are supported. 

It is an aim of the present invention to overcome or at least mitigate these 
problems. 

The present invention provides in one aspect a method of transmitting data in a 
communications system to take into account networks capable of supporting 
different service levels, , wherein i) a service request message is sent to a 
network across which the data is to be transmitted; ii) a response message is 
issued from the network identifying the service levels supported by the network; 
iii) the data is marked with a service identifier identifying a service level selected 
from the service levels supported by said network; and iv) said marked data is 
transmitted across the network in accordance with the identified service level. 

Preferably, the network comprises a plurality of nodes, at each of which the 
service identifier of a received data is examined and translated into a forwarding 
behaviour. In one embodiment the data is Internet Protocol (IP) packets, and the 
service identifier is in the form of a Differentiated Services code point (DSCP). 

Also, in the described embodiment, each data packet has a packet header and 
said code point is located in an 8-bit field in bit positions 8 to 15 of said packet 
header. The response message returns the service levels in the form of a list of 
DiffServ code points. 

The present invention also provides data transmission circuitry for transmitting 
data over a communications network said data transmission circuitry comprising: 
means for issuing a service request message to said communications network; 
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and means for selecting from a list of returned service identifiers a class of 
service for transmitting a message and marking data of that message with the 
selected service identifier. 

The present invention also provides data receiving circuitry forming part of a 
communications network capable of supporting different classes of service for 
transmitting messages, said data receiving circuitry comprising: a store holding a 
list of service identifiers corresponding to classes of service capable of being 
supported by said communications network; and means for formulating a 
response message in response to receiving a service request message from the 
user to acknowledge said request, said response message containing the list of 
service identifiers. 

The present invention will now be described by way of an example with reference 
to the accompanying drawings, in which:- 

Figure 1 shows a generic network model of end-users being connected 
through an intermediate network; 

Figure 2 shows an example of how packets of a videophone application 
may be routed through the Internet from a sender to a receiver; 

Figure 3 shows the basic structure of a data packet; 

Figure 4 shows an IPv4 (Internet Protocol version 4) packet header; 

Figure 5 shows an enlarged view of the DS (Differential Services) field; 

Figure 6 shows the interface signals between the sending application and 
the DS CP gateway; and 

Figure 7 shows a BB (Bandwidth Broker) system. 

The embodiment described below discusses a DiffServ network that overcomes 
the scaleability issues of an RSVP network, while improving the existing DiffServ 
architecture by providing the end-users with a means of establishing the capability 
of the network before data transfer. 
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Figure 1 shows a general network cloud 4 that allows two end-users, i.e. USER A 
2 and USER B 6 to communicate. There are various types of networks and 
protocols that may be applied to this generic model. For example, the network 4 
might be any of the following: PSTN (Public Switched Telecommunication 
Network), PLMN (Public Land Mobile Network), Internet, Intranet, X.25, LAN 
(Local Area Network), WAN (Wide Area Network), etc. and the protocols might 
be even more numerous. 

Figure 2 shows an example where the network 4 is the Internet. It will be 
assumed that a videophone service needs to be provided between a sender 9 
and a recipient 10 over the Internet 4. Data packets that make up the video 
stream will be switched through the Internet from the sender 9 to the recipient 1 0 
using the IP (Internet Protocol) and routers R labelied 8a, 8b, 8c and 16 to route 
the data packets. 

A number of elements that are important to the DiffServ architecture need to be 
defined. There are 'edge' or leaf nodes (routers) 8a, 8b, 8c located at the 
borders of a network and either connect to an end-user via end-user connections 
11 or to another network 5 via a network connection 15. Intermediate nodes 
(routers) 16 occupy the 'heart' of the network and packets are passed to or from 
other intermediate nodes 16 or edge nodes 8a,8b,8c. 

Figure 3 shows the basic structure of a data packet comprising a header portion 
20 and a data portion 22. Two versions of the Internet Protocol (IP) are specified 
for DiffServ, i.e. either version 4 or version 6. Both versions include a header 
having a number of fields. In particular, the IPv4 header includes a TOS' (Type 
of Service) and the IPv6 header includes a Traffic Class* field. The main idea 
behind DiffServ is to modify the TOS (type of Service)' field in the header of an 
IPv4 packet, or the Traffic Class 1 field in the header of an IPv6 packet, to become 
a DS byte field known as the DS field. 
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Figure 4 shows the structure of the header for an IP packet in IPv4. It can be 
seen that the header consists of five 32-bit words W1-W5, where bits 8-15 of the 
first word W1 are used for the Type of Service (TOS) octet 26. Figure 5 shows 
the modified octet 26', which consists of a 6-bit DS field 28 used to mark the 
packet with a certain DSCP (Differential Services Code Point). The two 
remaining bits 29 are currently unused (CU). 

Each packet receives a particular forwarding treatment at each node based on 
the marked bit pattern which defines the DSCP's. That is, each node of the 
network contains a mapping table for translating each DSCP field into a specific 
per-hop behaviour (PHB). As is known, the PHB for a packet is the forwarding 
behaviour it receives at a given network node, for example "best effort" or 
"normal". Therefore, a network node inspects each received data packet and 
ascertains from the DSCP what the class or the priority of the packet is and how it 
should be forwarded. The bit patterns defining the code points (DSCP's) have 
been standardised to some degree by the lETF's DfffServ working group. A 
number of code points are shown in Annexe 1 taken from RFC (Request For 
Comments) 2474. 

The 8-bit DS field 26' is capable of conveying 64 distinct code points. From 
Annex 1, it can be seen that the code point space is divided into three pools 
where 'x' refers to either '0* or '1': 

- Pool 1 containing 32 code points that have been provisionally assigned as 
indicated. 

- Pool 2 containing 16 code points (Pool 2) to be reserved for experimental 
or Local Use, and 

- Pool 3 containing 16 code points, which are initially available for 
experimental or local use, but would be used for any other standardised 
assignments if Pool 1 is ever exhausted. 
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It can be seen that pool 1 has 1 EF (Expedited Forwarding) code point, 12 AF 
(Assured Forwarding) code points and several local use code points (CS0-7). 
Furthermore, the 12 AF code points consists of four AF 'classes' where each 
class has three code points representing levels of priority known as 'drop 
precedences'. For example, AF class 1 is composed of three drop precedences, 
i.e. AF1 1, AF12 and AF13. 

To use DiffServ, code points (DSCP's) are assigned at the edge nodes 8a, 8b, 8c 
of the network. In figure 2, the videophone service (sender 9) is aware of the 
QoS needed to support it and marks the DS field 26' in the packets it transmits 
with the required code point. The edge routers 8a, 8b, 8c would also contain 
traffic conditioning entities such as: meters, markers, droppers, and shapers that 
could re-mark a traffic stream or may discard or shape packets to comply with a 
desired traffic profile. 

In so-called basic DiffServ there is a danger that certain nodes of the intermediate 
network may not be able to support the selected DSCP in the packet. In that 
case, the node will remark the DSFIELD accordingly. The result may be a poor 
quality transmission or the video stream may be dropped altogether. 

The described embodiment of the invention avoids this as described below. 
Figure 6 shows the interface 11 between the sender 9 and the gateway to the 
network 4. The gateway is the edge router 8a attached to the sender 9. The 
interface 11 may be implemented by slight modifications to various existing 
signalling protocols including SIP, RTCP, Cops, SNMP, HTTP or a new 
'lightweight 1 protocol may be developed, for example an ASCII-based 
request/response protocol. 

The following sequence of events are executed prior to actual data transmission 
of the video stream. A sending application at the sender 9 wishes to transmit a 
video data stream for a videophone application through the network 4 to the 
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receiver 12. Firstly, the sender 9 issues a DSCP AVAILABILITY REQUEST 
message 42 addressed to the gateway 8a! The gateway 8a holds a list of the 
available DSCP's that the network can support. The gateway may also contain a 
user profile where only certain users may have access to certain DSCP's. This 
can be done on a cost basis, i.e. for a 'premium' class of service a higher DSCP 
will be made available at increased cost. The concept of 'user profiling' and 
'policies' are well known and beyond the scope of the present invention. Next, 
the gateway 8a responds with an OK message 44 to the sender 9 acknowledging 
the request message and carrying additional information that defines all the 
available DSCP's available to the application at the sender 9. If, for example the 
message is: 

OK(X,Y,Z) 

this informs the sending application at the sender 9 that classes X, Y and Z are 
available. The sending application is then able to start transmitting the RTP (Real 
Time Protocol) data streams 46 using DSCP's X, Y or Z, selected on a per-packet 
basis by the sending application. 

By requesting the supported DSCP's before data transmission, the sending 
application is able to act accordingly and classify packets based on this 
information thus improving the perceived quality of the IP video stream. In many 
applications, particularly video, packets have different importance. The 
classification of these packets can be made very efficient if the sending 
application knows in advance, which DSCP's are supported by the network. 

It is also possible that the list of supported DSCP's is changed in the gateway 8a. 
If so, the gateway -8a informs end-users about the change by using local 
multicasting, where the list of supported DSCP's is transmitted to all registered 
end-users at the same time or alternatively by direct unicasting where the list is 
only supplied to a single specified end-user address at any given time. It is 
beneficial for a network operator that end-users (customers) are dynamically 
updated about the supported DiffServ classes so that precious network resources 
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are riot wasted in trying to provision a particular service that cannot be supported 
for whatever reason. 

The present invention is interoperable with existing systems. Furthermore, 
important issues such as security and reliability are easily implemented. As with 
other signalling protocols, for example HTTP (Hyper Text Transfer Protocol) or 
SIP (Session Initiation Protocol), authentication of users or sending applications is 
made possible using known techniques, for example using public keys. If the 
sending party's request 42 is not acknowledged reliability can be achieved by re- 
transmissions. The sending party might use a simple time-out algorithm, where if 
a response is not received from a gateway within a predefined period, the DSCP 
AVAILIBILITY REQUEST message 42 will be re-transmitted. 

It has already been described that the present invention will be interoperable with 
existing Diffserv technologies. Therefore, concepts such as an RTP (Real Time 
Protocol) QoS Manager or a BB (Bandwidth Broker), introduced as part of the 
Differential Services architecture would still apply. The RTP QoS Manager is an 
object that may reside within or outside the sending application of the sender 9 
and whose purpose is manage and organise the packets particularly for 
multimedia traffic streams having real-time constraints. The BB is a functional 
entity used at a higher level in dealing with the control or resource management 
both within a DiffServ-capable network (i.e. intra-domain resource management) 
and between a plurality of DiffServ-capable networks (i.e. inter-domain resource 
management). 

Figure 7 represents a typical BB system with a client/server relationship, where 
collaborating network operators or customers may use a client terminal to enter 
various parameters relating to SLA (Service Level Agreements) and/or BAR 
(Bandwidth Allocation Requests), which have previously been established. 
DiffServ boundary nodes may act as both a DiffServ 'ingress node' and/or an 
'egress node' depending on the direction of traffic. Traffic enters at a Diffserv- 
capable network at a DS ingress node and leaves at a DS egress node. 
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Therefore, in figure 2 the node 8c is an egress router, which is the edge router 
responsible for transmitting the video stream packets to the second network 5. 
The BB server is able to communicate with edge routers to set up their 
corresponding traffic conditioning elements. 

Referring back to figure 2 it can be seen that in certain situations a data stream 
may 'cross* networks in trying to reach a final destination. For example, consider 
the case when the sending application at the sender 9 connected to a first 
network 4 wishes to transmit a video stream to a receiver 14 connected to a 
second network 5. Although, the sender 9 may have communicated with the first 
network over interface 1 1 where it was established which DSCP's are available in 
network 4, the sender 9 cannot be certain that the same DSCP's are supported in 
the second network 5. 

This problem may be solved by the BB, which could make a similar DSCP 
AVAILABILITY REQUEST message to the edge router 8d of network 5. The OK 
response contains a list of supported DSCP's in the second network 5, which the 
BB could forward back to the sender. The sender now has knowledge of which 
DSCP's are available in both networks. If the first network supports classes X, Y 
and Z, while the second network only supports classes X and Z, then the sending 
party knows that the video stream packets should only be marked with the 
DSCP's X and Z. If the sender 9 decides that the video stream to be transmitted 
needs to have the data packets marked with at least three DSCP's (X, Y and Z) to 
be adequately supported, then the video stream service will not be transmitted to 
the recipient 14, until the second network supports the Y class. 

The implementation of an 'inter-domain availability method' is possible as the BB 
in basic Diffserv describes the edge routers of DiffServ-capable networks each 
having an interface with the BB so that inter-domain resource management 
functions such as SLA's (Service Level Agreements) and BAR (Bandwidth 
Allocation Requests) may be performed, as shown in figure 9. It will be 
appreciated as described above that the BB element is at a higher level than the 
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routing network and as such the links 60, 62 and 64 are not the same as the links 
17 of figure 2. 

It should be realised that the BB is provided as an example of how the present 
invention may be incorporated into an element of the DiffServ architecture and is 
intended to be non-limiting. It would be appreciated by a man skilled in the art 
that the present invention may be adapted to other DiffServ elements equally 
well. 
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Annexe 1. 



Pool Codepoint space Assignment Policy Reference 



1 xxxxxO Standards Action [RFC24741 

2 xxxx11 EXP/LU [RFC2474] 
3- xxxxOI EXP/LU (*) [RFC2474] 



Pool 1 Code points (Guidelines from RFC2474) 

Name Space Reference 



CSO 000000 [RFC2474] 

CS1 001000 [RFC2474] 

CS2 010000 [RFC2474] 

CS3 011000 [RFC2474] 

CS4 100000 [RFC2474] 

CS5 101000 [RFC2474] 

CS6 110000 [RFC2474] 

CS7 111000 [RFC2474] 

AF11 001010 [RFC2597] 

AF12 001100 [RFC2597] 

AF13 001110 [RFC2597] 

AF21 010010 [RFC2597] 

AF22 010100 [RFC2597] 

AF23 010110 [RFC2597] 

AF31 001110 [RFC2597] 

AF32 011100 [RFC2597] 

AF33 011110 [RFC2597] 

AF41 100010 [RFC2597] 

AF42 100100 [RFC2597] 

AF43 100110 [RFC2597] 

EFPHB 101110 [RFC2598] 
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CLAIMS 

1. A method of transmitting data in a communications system to take into 
account networks capable of supporting different service levels, wherein: 

i) a service request message is sent to a network across which the 
data is to be transmitted; 

ii) a response message is issued from the network identifying the 
service levels supported by the network; 

iii) the data is marked with a service identifier identifying a service 
level selected from the service levels supported by said network; and 

iv) said marked data is transmitted across the network in 
accordance with the identified service level. 

2. A method according to claim 1, wherein the network comprises a plurality of 
nodes, at each of which the service identifier of a received data is examined and 
translated into a forwarding behaviour. 

3. A method according to any preceding claim wherein the data is Internet 
Protocol (IP) packets, and the service identifier is in the form of a Differentiated 
Services code point (DSCP). 

4. A method according to clajm 3, wherein each data packet has a packet header 
and wherein said code point is located in an 8-bit field in bit positions 8 to 15 of 
said packet header. 

5. A method according to any preceding claim, wherein said response message 
returns the service levels in the form of a list of Differentiated Services code 
points. 

6. Data transmission circuitry for transmitting data over a communications 
network said data transmission circuitry comprising: 
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means for issuing a service request message to said communications 
network; and 

means for selecting from a list of returned service identifiers at least one 
class of service for transmitting a message and marking data of that message 
with the selected service identifier. 

7. Data receiving circuitry forming part of a communications network capable of 
supporting different service levels for transmitting messages, said data receiving 
circuitry comprising: 

a store holding a list of service identifiers corresponding to classes of 
service capable of being supported by said communications network; and 

means for formulating a response message in response to receiving a 
service request message from the user to acknowledge said request, said 
response message containing the list of service identifiers. 
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